Typically a simulation based functional verification includes a simulator to simulate the design, and a test bench to provide inputs and verify outcomes from the simulated design. When the digital design needs to be verified, the verification is performed at different levels such as: block or a group of blocks or the complete design. Each of these targets (block or a group of blocks or the complete design) is called Design Under Test (DUT) during this verification process.
Hardware Description Languages (HDLs) are predominantly used to describe integrated circuit designs. Various HDLs exist in the market today such as Very High Speed Integrated Circuit HDL (VHDL), Verilog, and System Verilog. HDL may be used to describe a design at various levels of abstraction. For instance, VHDL supports many possible levels/styles of design description. These styles differ primarily in how closely they relate to the underlying hardware. Some levels focus more on the behavior and dataflow of a design, while other levels focus more on the structural and timing aspects of the design.
For example, integrated circuit designs may be described at the dataflow level of abstraction, often called the register transfer level (RTL). In this intermediate level of abstraction, a design is described in terms of how data moves through the design. At the heart of most digital systems today are registers, and an RTL model describes how information is passed between registers in the design. This movement is synchronized at specific points of time which are indicated by the changes of values of a special design signal commonly known as a clock.
A verification environment for a DUT includes a test bench, which gives the essential stimulus as inputs to the DUT and checks correctness of the working of DUT.
Typically, a simulator software (for example VCS from Synopsis, NCSIM from Cadence, Modelsim from MentorGraphics etc.) is used to simulate the DUT working. The test bench is usually hosted on the simulator software. The simulator software requires the hardware description representation of the DUT (example VHDL/Verilog). The test bench components are coded using Hardware Verification languages for e.g. Specman/e or System Verilog etc.
Test bench for transaction based verification (TVB) is the most prominent type of test bench architecture. In short, TVB uses the concept of transactions to raise the verification effort to a higher level of abstraction for the purpose of improved productivity.
A test bench provides a set of components to verify the DUT and report success and failure. But, there are scenarios where a test bench shows failure when it is not an actual case failure, called bogus fails/false negatives.
A transaction can be a high level transaction (HLT) like configuring the entire Memory mapped registers (MMR) of a design or “read all registers” or low level transaction (LLT) like    [Type=doRead; addr=0xFF; data=0xF]For example “read all registers” may involve several low-level transactions like the LLT. When the design is verified, the design is first configured. Test bench will provide the stimulus and monitor the response of the design. Then the response is compared with expected value to check the correctness of the design. It there is a match, it is pass otherwise it is failure. All designs have the configurability. As the number of test configurations increase, the number of test cases will increase in an exponential number. Increase in the number of test cases would entail license cost of the server that provides the simulation platform for the verification of the design and cost of the simulation tool.
One way to reduce the number of test cases is to configure the design multiple times in a single test case. One single test case comprises applying the stimulus, observing the response, and comparing the response with the expected response. There is a practical limitation associated with the configuring of the design multiple times in a single test case. When the configuration is being changed while the design is running, the configuration goes to both the test bench and the design. Therefore, when the design is operating, in the middle we are changing the configuration, there are times when the configuration seen by the test bench and the design are different. Because of these different configurations seen by the test bench and the design, there is mismatch between the response and the expected response. So the test may show a failure when actually it is not the case.
In the light of the above facts, there is a need for a smart test bench for improved transaction based verification of digital design to minimize bogus fails that can take into account the dynamic and random changes in the DUT configuration.